Software of the Month Club 1996 May

home *** CD-ROM | disk | FTP | other *** search

/ Software of the Month Club 1996 May / Software of the Month Club 1996 May.iso / mac / ISO9660 / ZIPFILES / GIM_313.ZIP / GIM14.DOC < prev next >

Wrap

Text File | 1995-07-09 | 38.7 KB | 756 lines

CHAPTER 14 Using GEDCOM to Share Genealogical Data Like most major genealogical computer products, GIM supports the GEDCOM standard. This standard allows different products -- even radically dissimilar products -- to share genealogical data with one another. In effect, this means that you can create a GIM folder from the genealogical data of virtually any product which also supports the GEDCOM standard -- even if that product runs on a non-DOS platform like UNIX or the Macintosh. Similarly, you can share your GIM folder with any of these other products. This chapter will tell you everything you ever wanted to know about GEDCOM, and GIM's implementation of GEDCOM. More or less in this order, this chapter will answer the following questions: AN INTRODUCTION TO GEDCOM What is GEDCOM? Why is it important? Where does it come from? Who uses it? GIM FOLDERS AND GEDCOM (or "There and Back Again") How does GIM use GEDCOM? How do I produce a GIM folder from a GEDCOM data file? How do I produce a GEDCOM data file from a GIM folder? What do GIM's different GEDCOM destinations mean, and why do I need them? What about character sets? ADVANCED GEDCOM TOPICS What about titles? Is GIM able to create folders from GEDCOM data that represents unrelated lists of persons, such as from the Social Security Death Index (SSDI) or the International Genealogical Index (IGI)? If I export my GIM folder to a GEDCOM file, and then read that GEDCOM file back into a second GIM folder, will the second folder be any different from the first? If so, in what ways, and why? GEDCOM MISCELLANY -- OPTIONAL READING FOR THE INTENSELY CURIOUS Where can I go to read the documentation which defines the GEDCOM standard? How strictly does GIM adhere to the published documentation? And now, after that introduction, and without further ado, let's dive in with both feet: AN INTRODUCTION TO GEDCOM What is GEDCOM? Why is it important? "GEDCOM" is an abbreviation for GEnealogical Data COMmunication. As its name implies, it is a method for communicating -- sharing -- data between different and often radically dissimilar genealogical sources. In essence, it's a common language that one computer must speak if it intends to make sense to any other computer. Every genealogical computer product speaks its own language, so to speak; it runs on a particular operating system (such as DOS, UNIX, or the Macintosh) which no other operating system can understand; and even if it runs on the same operating system as another product, it typically reads and writes data on your hard disk in a way that no other product can reliably interpret. If this sounds chaotic, it's because it is chaotic. All of these "languages", if you will, are something like the Tower of Babel, and this situation is never going to get any less chaotic than it is now. Without something like the GEDCOM standard, none of these products would be able to communicate with any other. However, the GEDCOM standard serves as a sort of "common second language", through which all genealogical computer products can communicate. Where does it come from? Who uses it? GEDCOM is defined by the Family History Department of The Church of Jesus Christ of Latter-day Saints, and it is copyrighted by the Corporation of the President of the Church of Jesus Christ of Latter-day Saints. Documentation describing the GEDCOM standard is published by the Family History Department, and is available from: Family History Department, 3T 50 East North Temple Street Salt Lake City, UT 84150 GEDCOM is implemented (to varying degrees) by all major genealogical computer programs, and by many others. GIM has been registered with and approved by the GEDCOM Developers Group of the Family History Department, as have many other computer software products. GIM AND GEDCOM (or "There and Back Again") How does GIM use GEDCOM? All of the GIM's GEDCOM functions described below are available from GIM's Folder Area by pressing the F5 key. In the GEDCOM Area, there are two basic options: F1, the GEDCOM Import function, will create a GIM folder from an existing GEDCOM file. F2, the GEDCOM Export function, will create a GEDCOM file from an existing GIM folder. How do I produce a GIM folder from a GEDCOM data file? First of all, you must have a GEDCOM file to work with. The LINCOLN sample GEDCOM files that were (or should have been) included on your GIM software diskette are examples. GEDCOM files can be obtained from a number of places. Most commonly, they are produced by another genealogical computer program (e.g., FamilySearch), although GEDCOM files for such things as European royalty, Mayflower passengers, and United States Presidents are readily available from various sources. Take your GEDCOM file and place it somewhere -- on a floppy disk, on your hard disk, or wherever. Then enter the GEDCOM Area by pressing the F5 key from the Folder Area. Press the F1 key to import the GEDCOM file into your GIM folder. A screen that looks like the Folder Area will appear; use it to point to your GEDCOM file and press return. Another screen that looks like the Folder Area will appear; use it to point to the directory where your new GIM folder should appear. After that's done, the process is automatic, and will require no interaction from you until it's all over. When the GEDCOM Import process is all over, you will want to use the GIM Utilities -- F5 from the Multi Area -- to reset GIN numbers, to match PIN and GIN numbers, and finally to check the folder for data integrity. See chapter 15, entitled "Utilities for a Folder", for more details. It is highly recommended that you DO NOT OMIT THESE STEPS!!! You may encounter any of the following items when importing a GEDCOM file to a GIM folder. Some of them are normal, and some are genuine problems. Here are descriptions of the issues, and their remedies: 1. You may be warned that the GIM folder that you are trying to create already exists. In this case you will be prompted to verify that you want to overwrite the existing folder. This is normal; however, be very careful how you answer this, because if you answer "yes", you may not be able to recover the overwritten folder. 2. If you try to import or export when directory, file, or folder names are empty, GIM will complain and ask you to try again. This is normal. 3. If you try to import or export when directory names are not blank, but do not exist on your system, you will be asked whether you want GIM to create them. This is normal. Be careful how you answer, because a "yes" answer will cause the directory to be created, and a "no" answer will cause GIM to use the current directory; however, neither answer will abort the import or export function. 4. When the import begins, GIM will display each of the names of persons and families that it encounters in the GEDCOM file. It will also display comments about who created the GEDCOM file, when it was created, and by what software product. GIM will also include these notes in your GIM folder's Folder Notes; press control-F5 from the Multi Area to view them. 5. This item is probably the most critical. While the import function is underway, GIM may encounter a GEDCOM line that it doesn't expect, or doesn't know how to deal with. This is not desired behavior. It could be caused by all kinds of things, including a software error in GIM, and including a software error in the program that produced the GEDCOM file. GIM will report all such things in the lower window of the GEDCOM Import Area, and will also report them in a log file that has the same name as your GEDCOM file, but with the extension .LOG. You will be asked to send your GEDCOM file and this LOG file to the GIM Authors. Please do so; this will help us fix GIM to make it more robust. How do I produce a GEDCOM data file from a GIM folder? Naturally, you must have an existing GIM folder before you can use this function. The LINCOLN sample folders that were (or should have been) included on your GIM software diskette are examples, but we assume that you have one or more of your own. Enter the GEDCOM Area by pressing the F5 key from the Folder Area. Then press F2 to export your GIM folder to a GEDCOM file. As you did with the GEDCOM Import, select your GIM folder and your destination directory using the Folder-Area-like screens that appear. Next, it is necessary to select a destination. There are several destinations available: PAF 2.2 (or later), Ancestral File, TempleReady, Universal, and GIM. The meanings for these will be explained in a moment; for now, type U for Universal, which is the recommended choice for most purposes. Next, it is necessary to select a character set. The choices are: No diacritics, IBM PC, and ANSEL. These will also be explained in a moment. For now, pick IBM PC, which is sufficient for the purposes of this example. Once that's done, the export process is automatic, and will require no interaction from you until it's all over. You may encounter any of the following items when exporting a GIM folder to a GEDCOM file. They are normal: 1. You will be warned if the GEDCOM file that you are trying to create already exists in the directory you named. You will be asked if you want to overwrite the old file with the new one. 2. If you try to import or export when directory, file, or folder names are empty, GIM will complain and ask you to try again. When the export begins, GIM will display each of the names of persons and families that it encounters in the GIM folder as it writes them to the GEDCOM file. There are no other problems that you are likely to encounter when you are doing a GEDCOM export. What do GIM's different GEDCOM destinations mean, and why do I need them? The different GEDCOM destinations are: 1. PAF 2.2 (or later) Select this destination if your GEDCOM file is going to be read into version 2.2 (or later) of Personal Ancestral File. Selecting this destination will cause GEDCOM to create a GEDCOM file that, let us say, knows about PAF's limitations. Among other things, PAF wantonly ignores any GEDCOM notes other than those associated with persons -- which means that all family notes and all event notes must be bunched together in one pool, or PAF will ignore them. Selecting a destination of PAF 2.2 will accomplish this. (Selecting a destination of PAF 2.2 will also translate LDS temple names into their five-letter abbreviations. The Ancestral File destination also performs this translation.) We recommend that you use it whenever you know that you're sharing data with a PAF user. There is no destination for PAF 2.1 or for earlier versions, because those versions deal with GEDCOM in a very weird way. Actually, it's not weird; it's just old. The GEDCOM standard has changed with time, and those old versions of PAF are incompatible with the current standard. We have elected not to support that older implementation, partly because it's so old -- PAF 2.2 is based on the October 1987 version of the GEDCOM standard! -- but mainly because we almost never see it anymore. 2. Ancestral File This should be used as a destination whenever you plan to submit your genealogy to the LDS Church's Ancestral File. As stated earlier, GIM is registered and approved by the GEDCOM Developers Group of the LDS Family History Department for submitting GEDCOM format data to their Ancestral File. When you use GIM to submit data to Ancestral File, use this destination to create your GEDCOM file. This destination is essentially the same as the Universal destination, with two exceptions: it uses five-letter abbreviations for LDS temples; and it explicitly lets the LDS Family History Department know that you intend this GEDCOM file to be included in its Ancestral File database. (For GEDCOM experts: this means that it sets the DEST tag to ANSTFILE, which is what the Ancestral File people expect.) This destination formats notes in the same manner that the Universal destination does; however, we have recently been told authoritatively that the Ancestral File ignores all notes sent to it, so the note format is essentially irrelevant. We leave them in, knowing that they won't be used, for the very sensible reason that doing so puts the responsibility for omitting them on the proper shoulders -- that is, not on ours. For more information about contributing to Ancestral File, see the FamilySearch publication entitled "Contributing Information to Ancestral File", which is available from most LDS Family History Centers, and which may be ordered at no charge from the Salt Lake Distribution Center (see Part C of Chapter 10 of this GIM documentation for their address); give them order number 34029. You might also want to get the publication "Correcting Information in Ancestral File". That order number is 34030. 3. TempleReady A number of GIM users have asked for the ability to create TempleReady diskettes using GIM. If you are one of those, this is the destination to use. When this documentation (and other literature) refers to a "TempleReady diskette", what is actually meant is simply a diskette which contains a GEDCOM file which has "TempleReady" as its destination (that is to say, for GEDCOM experts, the GEDCOM file must have the line "1 DEST TempleReady" in its HEADer record). (This means that you shouldn't try to use any other GIM GEDCOM Export destination if you intend to use TempleReady; TempleReady won't recognize that GEDCOM file, even if it is perfectly valid in every other way.) So to create a TempleReady diskette using GIM, select the TempleReady destination from a GIM GEDCOM Export. The resulting GEDCOM file can then be placed on a diskette and taken to your local LDS Family History Center for use with FamilySearch. Please note, when doing so, that ALL of the families and individuals in your folder will be included in the resulting GEDCOM file. This is in contrast to PAF, for example, which prompts you to identify families and individuals one by one for inclusion on the TempleReady diskette. Because of this, if you only want to include a single family or a single branch on your GIM TempleReady diskette, it is important that you prune off that family or branch into its own folder before selecting this option. (See chapter 12, "Pruning Folders", for details.) It is strongly recommended that you double check your submission info and make sure that it has been entered, and that it is correct. (See chapter 10, "Generating Printed Forms", for details about the submission info.) (Note that if you prune a folder from a parent folder, the parent's submission info will carry over into the pruned folder.) TempleReady will prompt you for this information, which will be included automatically from your submission info, so you can save yourself a step if your submission info is accurate to begin with. After you select TempleReady as your destination (and after you select a character set), GIM will prompt you for a temple name. This assumes that your names will go into a Family File in your name at the temple nearest you. GIM requires that you enter the name (or abbreviation) of one of the LDS temples at this point, just like you would if you were entering a place name for a person's endowment or sealing. If you intend to submit your names to a Temple File rather than a Family File, and if you don't care what temple the names are submitted to, then enter the name of any temple in response to this query. It won't matter what name you pick in that case. Let the GEDCOM export run to completion, then (like we said earlier) the resulting GEDCOM file can be taken to your nearest LDS Family History Center for use with FamilySearch. Your Family History Center should have written instructions describing how to use FamilySearch, so we will refrain from describing its use in detail here. Specifically, your local LDS Family History Center should be able to provide you with a FamilySearch user's guide, which is several dozen pages long, and which contains detailed instructions on the use of TempleReady, as well as the other components of FamilySearch. They should also be able to provide you with a four- page guide entitled "Introduction to TempleReady". This may be obtained at no charge from the Salt Lake Distribution Center. See Part C of Chapter 10 of this documentation, entitled "Generating Printed Forms", and subtitled "The Preprinted Family Group Record", for their address. When you contact them, ask for item number 34596. 4. Universal You will notice that there is no destination specified for any of the other myriad of genealogy programs that are available, such as Brother's Keeper and others. This is partly because we aren't as familiar with them as we are with PAF and with Ancestral File. But mainly, it is also because we expect most of them to be more fully GEDCOM compliant than PAF is, (strange as that may sound). In other words, we expect the Universal destination to work for most GEDCOM-compatible programs in most cases. The Universal destination adheres in all ways to the GEDCOM standard, and as such it should theoretically be accepted by any program that speaks GEDCOM. It differs from the PAF destination chiefly in its use of notes, which are attached to families and events, instead of lumped together in one pool for each individual. It differs from the Ancestral File and PAF destinations in its use of long names for LDS temples, instead of the standard five-letter abbreviations that these LDS-oriented software products expect. Naturally, if you encounter a program that can't or won't read a GEDCOM file that is generated with a destination of Universal, we would like to know about it. When that situation is brought to our attention, we will create a new destination category for that software product, and use it to accommodate that product's needs. 5. GIM This destination creates a GEDCOM file which can be re-imported into GIM in such a way as to create a resulting GIM folder which was as much like the original folder as possible, while still adhering to the GEDCOM standard. To some degree, the resulting GIM folder will not be exactly the same as the original; it cannot be, and still be transmitted through a GEDCOM file which adheres to the standard. For details, see the discussion of this question below, under the section heading "Advanced Genealogical Folder Exchange". At the present time, this destination differs from the Universal destination only in the fact that source notes and research notes are denoted by the identifier "GIM SOURCE NOTES" and "GIM RESEARCH NOTES", whereas with the Universal destination, they are only identified as "SOURCE NOTES" and "RESEARCH NOTES". What about character sets? There is a certain amount of confusion in the computer industry regarding the use of diacritical marks such as umlauts, accents, and so forth. While the industry is pretty well settled on the way to represent the basic Latin alphabet used by the English language, this is not at all true of the marks use by foreign languages. Without wanting to get too technically involved, let's just say that there are a number of different ways of representing these marks, and every computer system uses its own way of doing so. As a result, there is one character set for the Macintosh, another for MS-Windows, half a dozen or more code pages for MS-DOS, no one of which is compatible with any other. Further adding to this alphabet soup of character sets are a long list of sets defined by international organizations. In an effort to address this problem, the GEDCOM standard settled on one of the international standards, called ANSEL (which stands for "American National Standard for Extended Latin Alphabet Coded Character Set for Bibliographic Use"). The fact that GEDCOM defines a standard is the good news. The bad news is that not everybody accepts or implements it. As a result, there are still many genealogical software products which read and write diacritical marks in their own native character set, which naturally makes life miserable for (let's say) a user of DOS software who is trying to share data with a user of Macintosh or MS-Windows software. Now, with that much background, let's get back to the question, "What about character sets?" GIM currently provides support for three: No diacritics, IBM PC, and ANSEL. A fourth one -- MS-Windows -- will be available in a near-future release. These three are discussed below in turn. NO DIACRITICS: When you select any of the other destinations, GEDCOM translates any diacritics it encounters into the standard alphabet, according to standard rules. For example, it translates "ü" as "ue", and trans- lates "å" as "aa". (The rules that are used are described in detail in Appendix E.) This is principally of use (or interest) only when sharing GEDCOM data with PAF, because PAF simply doesn't handle diacritics very well at all. No matter whether the native (IBM PC) or the ANSEL set is used, PAF simply ignores the diacritic; the result is that the name "Müller" becomes simply "Muller". Selecting the "no diacritics" character set at this point is at least a simple-minded step ahead of PAF. This choice replaces "ü" wherever it is found with the standard "ue", meaning that "Müller" becomes "Mueller", which is a slightly more acceptable transliteration of the name. As a result of all this, the "no diacritics" selection is recommended for use with PAF, and is not recommended for any other use. IBM PC: This is the native character set used with MS-DOS, assuming that you are using the United States code page (437). GEDCOM transfers using this character set are quite a bit faster than using any other character set, because there is no translation involved. On the other hand, this character set is not at all portable, and its use is technically in violation of the GEDCOM standard. However, its use is supported by GIM because so many other genealogical software products provide it, and in fact some of them don't provide anything else. This character set is recommended if, and ONLY if, you know that you are communicating with another MS-DOS machine which is using the United States code page (437). ANSEL: This is the GEDCOM standard character set. As discussed above, this character set preserves diacritical marks across all computer systems, as long as they are all implementing the ANSEL character set correctly. This character set is recommended for all destina- tions, except for use with PAF, and except in cases where you know that the receiving software doesn't speak ANSEL. In particular, it is especially recommended for use with the Ancestral File and TempleReady destinations. ADVANCED GEDCOM TOPICS What about titles? Titles are used by certain software products to augment a person's name. Examples of titles include "Dr.", "Rev.", "Captain", "Jr.", "III", and "Countess of Leicester". There is a certain amount of ambiguity in the GEDCOM community about how these titles should be communicated in a GEDCOM file, and how they should be combined to form full names. That is, if a title appears in a GEDCOM file, should it be placed before or after the first and last names to form a full name? The problem is not simple, since some titles naturally fall before ("Dr.") and some after ("III") a person's name. In addition, in some cases (e.g., "Alfred Lord Tennyson"), they belong within the full name. Some have suggested that titles not be combined with the first and last names at all, because of this kind of ambiguity. Some proposals have been suggested as ways of improving this situation. Generally they center around the idea of defining "prefix titles" and "suffix titles". Using this scheme, things like "Dr." and "Captain" would be prefix titles, and "Jr." and "III" would be suffix titles. Some kind of a solution like this is inevitable, but nothing has been formally defined at the present time. Because the GEDCOM community isn't settled on how to do this, the GIM authors have seen all kinds of variations. It's difficult to deal with them all consistently, but here's what we have done: If the TITLe field in a GEDCOM file contains a forward slash ('/') character, then anything before the slash is treated like a prefix title, and anything after the slash is treated like a suffix title. Otherwise, if the TITL field is one of a set of defined prefix titles, it is treated as a prefix title; otherwise it is treated as a suffix title. The set of defined prefix titles is "mr mrs miss ms dr sir pvt private lt lieutenant maj major capt captain rev reverend deacon". (Titles are compared to this list after punctuation is removed, and the comparison is case-insensitive. However, these modifications only affect the comparison; the original, unmodified title is used to create the person's name.) You can add to the list of predefined prefix titles by editing your gimvar.aux file by hand, using a text editor (NOT a word processor!), and adding your other prefix titles after the line which reads "~ GEDCOM additional prefix titles". Ordinarily, that line is a blank line, until you add to it. So for example, to add "President" and "Bishop" to the list of prefix titles, find that (usually blank) line and replace it with a line which reads: president bishop NOTE: ALL OF YOUR ADDITIONS MUST BE ON ONE LINE! Do not add any additional lines to the gimvar.aux file!! Please feel free to share such additions with the GIM authors, so that we can make them available to everyone. Is GIM able to create folders from GEDCOM data that represents unrelated lists of persons, such as from the Social Security Death Index (SSDI) or the International Genealogical Index (IGI)? Absolutely! Naturally, in that case, the GIM folder will consist of unrelated individuals -- in other words, there will be lots of persons and notes in your folder, but no families. GIM has no problem dealing with this kind of folder, but you may think that such a folder may not feel natural. That's because GIM is designed with family relationships in mind, and when they are absent, it's not possible to use arrow keys to navigate around the folder. However, all of GIM's other functions are available, and they are often valuable tools in such cases. GIM LISTS, for example, can be used to search each of these persons for items of interest; but just be aware that you can't search for families, because there aren't any. In other words, yes it can, but don't let the result bother you too much. If I export my GIM folder to a GEDCOM file, and then read that GEDCOM file back into a second GIM folder, will the second folder be any different from the first? If so, in what ways, and why? There are a couple of items which will not translate correctly in such a scenario. These are as follows: GIM's "code" value -- which is available from the Person Edit screen -- is not included in a GEDCOM export. Naturally, therefore, it won't be restored when the GEDCOM file is re-imported. GEDCOM does not allow forward slashes in person names, but GIM does. If forward slashes are used in person names, they will be translated into backslashes when the GEDCOM file is created. Naturally, when this GEDCOM file is re-imported, the backslashes will not be restored. (How can the GEDCOM importer know whether a backslash was originally a backslash or a forward slash?) The folder notes will be quite different in the two folders. This is because a GIM folder's folder notes are not included in a GEDCOM export, and the GEDCOM import creates brand new folder notes from scratch during the import process. GEDCOM MISCELLANY -- OPTIONAL READING FOR THE INTENSELY CURIOUS Where can I go to read the documentation which defines the GEDCOM standard? As we stated earlier, the documentation can be obtained from the Family History Department of the LDS Church. This documentation is intended for programmers only, and is not necessary for non-programming purposes. How strictly does GIM adhere to the published documentation? To the best of our knowledge and belief, GIM's GEDCOM Export functions produce GEDCOM files that are fully compliant with the most recent publication of the GEDCOM standard. GIM produces GEDCOM files that can be read without difficulty by PAF and Brother's Keeper, and GIM produces GEDCOM files that are approved for Ancestral File submissions by the Family History Department of the LDS Church. The GEDCOM standard is, however, very rich and powerful, and it is not unlikely that other software products may produce GEDCOM compliant files that GIM can't understand. GIM has made every attempt to understand and comply with the GEDCOM files produced by most major software products, but we can't guarantee that we can understand them all. As stated earlier, if you should encounter instances where GEDCOM files are incompatible with other software, the problem could be either with GIM or with the other software; in either case, we encourage you to bring them to our attention.